Agentic Multi-Channel Collections Outreach at Interval

In summer 2025, I was asked to overhaul Interval's collections outreach system.

At the time, our process was a basic dunning flow: a prewritten SMS message sent at fixed intervals.

For people unfamiliar with the term, dunning is the process of reminding customers about overdue invoices and collecting payment. Traditionally that meant snail mail; today it usually means SMS, email, and phone outreach, often with templated messaging. Our goal was to move beyond static reminders and build a conversational system that could adapt to each account while still respecting strict policy boundaries.

The challenge was not just "add another channel." It was replacing a single-channel conversation engine with a coordinated workflow across SMS, email, and call operations.

Where the old system started to break

The existing setup worked for simple cases, but started to bottleneck as volume and scenario complexity increased:

• Rigid sequencing: every account followed nearly the same timeline, even when behavior signals suggested a different next action.
• Single-channel assumptions: logic was built around text-only communication and did not generalize cleanly to email threads or call outcomes.
• Context fragmentation: important history lived in different systems, so each outreach action risked acting on partial information.
• Poor controllability: it was hard to enforce nuanced policy and escalation behavior without piling up brittle conditional logic.

If we simply bolted on email and voice to the existing pattern, we would have multiplied complexity without improving outcomes.

Why we designed it as a graph

There is a lot of hype around agentic graph workflows, and some of it is warranted. In production, though, most of these systems are not magic: they are explicit orchestration over LLM calls, with guardrails at each step.

At a practical level, a graph gives you a way to manage three things at each step:

• what context is visible
• what prompt/instruction layer is active
• what tools the model is allowed to call

That is why this pattern worked for collections. We used the graph to enforce progressive disclosure: do not reveal information, instructions, or capabilities until they are needed for the current decision. That cut confusion and prompt interference, and it kept the model on the immediate objective instead of blending every rule into one oversized context window.

The graph also modeled branching workflows, but its main value was control: only as much context and as many tools as the moment required.

Building one control plane for three channels

Once the graph worked as the control structure, we connected it to each delivery channel:

• SMS for direct reminders and quick follow-ups
• Conversational email for longer-form dispute or commitment discussions
• Call system integration for voice outreach and escalation paths

The key design decision was to keep all channels inside one orchestrated workflow instead of giving each channel its own independent "brain." That shared control plane made cross-channel continuity possible. A reply in email could directly influence what happened next in SMS or voice, and vice versa.

How we handled agent behavior safely

Our implementation used a custom harness (conceptually similar to LangChain/LangGraph-style orchestration), but with stricter production constraints around policy and capability boundaries.

We wanted the benefits of conversational AI without letting the model operate as an unconstrained assistant. The system needed bounded autonomy:

• it could adapt language and cadence to account context
• it could choose among valid next workflow steps
• it could not bypass policy gates
• it could not message outside approved windows
• it could not skip required human review on high-risk paths

Problems we hit along the way

The build was not just an architecture exercise. We had to solve several practical issues:

• State coherence over time: interactions from earlier in the week had to influence later decisions, even across different channels.
• Channel-specific constraints: each medium had different timing, formatting, and compliance expectations.
• Failure-mode handling: we needed reliable paths for non-responses, ambiguous replies, bounced messages, and conflicting signals.
• Human handoff quality: escalations had to preserve context so agents were not re-triaging from scratch.

The graph model gave us the right abstraction to solve these consistently instead of case-by-case.

What this project changed for me

Leading this system taught me that useful agentic workflows are mostly an orchestration problem, not a prompt trick.

In collections, success depends on timing, clarity, and trust. A graph-based design helped us turn those principles into something operational: one system that could reason across channels, adapt to customer behavior, and still behave predictably under pressure.